[Previous] [Next] [Index] [Thread]

Re: _DNS_ security problems

For what it's worth, I agree with Bob that DNS should be taken out of
the picture as far as Java is concerned.  I can't see any good reason
that Java should be rely on the DNS for its security measures.
Connection restrictions should be entirely IP address-based.

People using DNS names for Web _server_ access restrictions should
also be warned that this mechanism is subject to DNS spoofing.  It's
better to restrict access by IP number or subnet.

Lincoln

Bob Denny writes:
 > 
 > 
 > On Feb 25, Dan Stromberg <strombrg@test34a.acs.uci.edu> wrote:
 > > Subject: _DNS_ security problems
 > >
 > > [...] The DNS should still be fixed, it's just a longer-term, 
 > > (much) more time-consuming fix.  If there is no longer a list of what 
 > > addresses have been delegated where [...etc.]
 > 
 > Yes, this is a topic for the bind list. I disagree that the solution lies in 
 > modifying DNS, which works very well for its intended purpose, and not very 
 > well as a secure identification mechanism (sometning is was _not_ designed to 
 > do). The protection, in my opinion, needs to be at a higher level. IMHO.
 > 
 > In any case, couldn't Java do a getpeername() on the socket used to grab the 
 > 'master' class? Then it could use the peer IP address as the source host, 
 > refusing to load from or connect to any other IP address. Forget even _using_ 
 > DNS except to get the initial connection to the applet source. It seems 
 > unlikely that the IP address of the host could (or should be supported to) 
 > change during the class group loading sequence. I suppose it could change 
 > during the time that the applet is running, but I'd think it would be OK for 
 > the applet to fail in that case also.
 > 
 > Eric Rescorla, in a private note to me a few days ago, pointed out the (I 
 > coulda had a V8) difference between authenticity and safety of downloaded 
 > stuff. The issue of getting something that is guaranteed traceable to 
 > "someone" is one issue. Whether that someone, and the applets (s)he may put 
 > up, is or can be malicious is the other. If they are, at least you know where 
 > you got the malicious software from, and can send Jake the leg-breaker after 
 > them.
 > 
 >   -- Bob (newcomer to these issues, pardon if the above seems silly)
 >
References: